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Appl. No. 10/014,893 
Amdt. dated October 13, 2006 

Reply to Final Office Action of August 15, 2006 

AFTER PINAL EXPEDITED PROCEDXmE 
KEMftRKS 

Claims 1, 2, 3, 4, 5, and 6 were pending in the 
application at the time of examination. Claims 1^ 2, 3, 4, 5, 
and 6 remain rejected under 35 U,S.C. 103(a). 

Claim 1 stands rejected 5 U.S.C. 103(a) as unpatentable 
over U.S. Patent No. 6,092,196 to Reiche (hereinafter, Reiche) 
in view of U.S. Patent No. 6,970,904 to Rode (hereinafter. 
Rode) . Applicants thank the Examiner for the clarification of 
the rejection. However, Applicants continue to respectfully 
traverse the obviousness rejection of Claim 1. 

To establish a prima facie case of obviousness, the MPEP 
directs: 

ESTABLISHING A JWIMA HICIE CASE OF OBVIOUSNESS 

To establish a prima facie case of obviousness, 
three basic criteria must be met. First, there 
must be some suggestion or motivation, either in 
the references themselves or in the knowledge 
generally available to one of ordinary skill in 
the art, to modify the reference or to combine 
reference teachings. Second, there must be a 
reasonable expectation of success* Finally, the 
prior art reference (or references when 
combined) must teach or suggest all the claim 
limitations* The teaching or suggestion to make 
the claimed combination and the reasonable 
expectation of success must both be found in the 
prior art^ and not based on applicant's 
disclosure - 

MPEP, § 2142, 8th Ed., Rev. 5, p. 2100-125 (August 2006). 
This section of the MPEP makes it clear that to establish a 
prima facie obviousness rejection, there must be a proper 
suggestion or motivation to combine reference teachings. 
In the prior response. Applicants stated in part: 

The Office Action further stated: 

Reiche does not explicitly indicate that 
user ID is a randomized user ID- 
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Rode teaches a system for controlling 
access to system resources (Abstract) that 
includes a unique identifier for the user 
as taught in Reiche, but further teaches' 
that the identifier can be a uniformly 
chosen random number (Column 2, lines 45- 
54) • 

The motivation for this modification was given as "to 
allow an identifier to be chosen without contain [SicJ any 
personal information about the user, allowing the system 
to keep the user anonymous. However, with respect to the 
client ID^ Reiche, as quoted above ^ taught "Authentication 
Daemon 124 will generate a unique 4 byte client ID." 
Accordingly, the client ID of Reiche does not contain any 
personal information about the user and so Reiche provided 
the very feature cited as the motivation for modifying 
Reiche. Again, when Reiche is considered as a whole 
Reiche teaches that the motivation for the combination of 
references is not well founded. 

These remarks were not addressed in the Final Rejection, and 
the identical motivation was stated- Thus, these facts stand 
admitted, and the motivation is not well founded. 

Nevertheless, Applicants will address the additional 
remarks in the final office action in further detail. Again, 

Claim 1 recites in part: 

receiving a resource request, said resource 
request including a rights key credential. 

Thus, a single element, a resource request, is received and 
that element includes a rights key credential- The rights key 
credential in turn includes: 

said rights key credential comprising; 
at least one key . ► . ; and 
a resource identifier. 

Claim 1 expressly recites that the at least one key and a 
resource identifier are part of the rights key credential. 
Claim 1 does not recited just any resource identifier, but 
rather a specific identifier: 
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said resource identifier comprising a resource server 
peer group ID and a randomized user ID 

The explicit claim language in Claim 1 has recast in the 
rejection and reduced to a gist, e.g., 

- . . Reiche teaches an authentication system that 
allows a client to make a request to a server using a 
URL(Colmnn 8, lines 47-49) this is a uniform resource 
location, meaning a request for a identified resource. As 
part of this URL request is the address of an 
authentication program on the customer server (Column 8, 
lines 47 -51; Column 9, lines 57 -63) since this is a URL 
request, as part of any URL is the server domain as see 
[Sic] in Figure 46A where the Some Resource Server Peer 
Group, for examiner in www.uspto.gov^ uspto.gov would be 
considered the resource server peer group ID as defined in 
the specification of the instant application which has to 

be present in all URL requests So all the 

limitations of the intention [Sic] are covered by the 
reference Reiche - 

As noted above. Claim 1 explicitly stated that the 
resource identifier included "a resource server peer group ID 
and a randomized user ID." There has been no citation or 
explanation of any motivation to modify the standard URL used 
as the basis of the rejection to include this specific resource 
identifier. Further, Reiche expressly differentiates between a 
client ID and a user ID. The Examiner's attention is called to 
Col. 11, line 66 to Col. 12, line 24 where Reiche explicitly 
described what is included in the various URLs. None include 
the user ID described by Reiche. Thus, Reiche cannot provide 
any motivation for modifying the standard URL used as the basis 
for the rejection to read on the resource identifier recited in 
Claim 1 that includes a randomized user ID. Accordingly, these 
are still further reasons why the obviousness rejection is not 
well founded- 
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AFTER FINAL EXPEDITED PROCEDURE 

Next, the rejection mixes and matches the teachings of 
Reiche and so fails to consider the reference as a whole as 
required by the MPEP. Reiche teaches that different URLs are 
generated in different parts of the authentication process and 
transmitted with redirection commands. The request at Column 
8, lines 47 -51 Is the initial request to "a secure customer 
HTTP server." At Col. 9, lines 8 to 11, a modified request is 
sent via redirection "to the client browser." At Col. 9, lines 
38 to 42 yet another request is submitted by the client browser 
to an authentication server that is different from the customer 
server. At Col. 9, lines 51 to 56 still yet another 
modification of the URL is sent by the authentication server to 
the client browser with a redirection command. 

The rejection, as quoted above, lumps the multiple 
requests to different entities together and so apparently fails 
to recognize that receipt of multiple different requests has 
.occurred prior to the description at Col. 9, lines 57 to 53. 
The use of multiple requests from Reiche in the rejection 
demonstrates that Reiche teaches away from the receiving 
operation recited in Claim 1. The rejection has provided no 
rationale for picking and choosing elements from among the 
various requests to different entities described by Reiche. 
Further, as noted in the prior response and incorporated herein 
by reference, the rejection fails to treat the elements of 
Reiche consistently, 

As noted above, Reiche at Col. 11, line 66 to Col. 12, 
line 25 explicitly described what is included in the various 
URLs. None of the URLs or the cookie include the user ID 
described by Reiche. Accordingly, Reiche explicitly teaches 
away from the interpretation provided in the rejection. Also, 
the rejection has provided no rationale for modifying the 
explicit structures defined by Reiche to read on the rights key 
credential of Claim 1 as explicitly defined in the claim. 

Next, the rationale for continuing the rejection stated: 
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. ♦ - Further^, Reiche teaches using a encrypted 
simple private key to authenticate a user (Column 9, lines 
1-6) which is passed in the HTTP header (Column 9, lines 
53-56) , which is also how the rights key credential is 
used in the instant application . , . 

This further mischaracterizes both the language of Claim 1 
as quoted above and Reiche, Col. 9, lines 1 to 6 stated: 

At step 212, a special URL is constructed from the 
row ID, client ID, transaction ID and a checksum of these 
three values. This information is then encrypted using a 
simple private key encryption algorithm, uuencoded and URL 
encoded to facilitate transmission (step 214) , 

The row ID, client ID transaction ID and a checksum are 
encrypted by the authentication daemon 124 of Reiche using a 
private key encryption algorithm. This portion of Reiche does 
not say the private key is passed in the HTTP header. It is 
the "information," i.e., the "the row ID, client ID, 
transaction ID and a checksum, " which is encrypted, uuencoded 
and URL encoded to facilitate transmission. 

Column 9, lines 49 to 56 of Reiche stated: 

At step 234, another special URL containing the AD 
authentication table row ID, client ID, transaction ID and 
checksum of these three values Is constructed- The AD CGI 
program 114 then issues (step 236) , to the client browser, 
a 302 redirect to the AD 124 on the customer server 120 
passing, in the HTTP header, the special UEOL as a 
parameter. The special UKL points, in fact, to the ad 124, 
passing as a parameter of the transaction ID data^ 
(Underline emphasis shows portion extracted and used in 
above quoted portion of rejection.) (Bold for emphasis) 

The special URL is what is passed in the HTTP header, and 
so yet again, it appears that the special URL is being equated 
to the key rights credential • This is but further evidence 
that Claim 1 has been reduced to a gist. 
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AFTER FINAL EXPEDITED PROCEDURE 

As quoted above. Claim 1 expressly recited that the resource 
request includes a rights key credential and then that the 
rights key credential includes at least one key and a resource 
identifier. Claim 1 then further defines the resource 
identifier. 

The special URL of Reiche does not include a key as 
recited in Claim 1 or any user ID, but rather "another special 
URL containing the AD authentication table row ID, client ID, 
transaction ID and checksum of these three values is 
constructed." Reiche carefully distinguishes this special URL 
from the one described earlier and expressly stated that four 
items where included and those four items did not include any 
type of User ID. Further, the special URL is described as 
pointing to "AD 124." This conclusion is also supported by the 
express description of the URLs and cookie described by Reiche 
as previously noted- 

The Office Action failed to provide any rationale on how 
this section of Reiche provides any teaching, suggestion, or 
disclosure of the at least one key to provide access to a 
resource on said data communications network,. • as recited in 
Claim 1, or including any type of user ID. Therefore, the 
Office Action failed to show how the cited references, alone or 
in combination, taught or suggested all of the claim 
limitations of Claim 1. 

For each of the foregoing reasons, the prior art reference 
(or references when combined) failed to teach or suggest all 
the claim limitations; therefore, a prima facie obviousness 
rejection has not been made. Applicants respectfully request 
reconsideration and withdrawal of the obviousness rejection of 
Claim 1. 

Applicants respectfully traverse the obviousness rejection 
of each of Claims 2, 3, 4, 5, and 6* With respect to Claims 2, 
3, 4, 5, and 6, the above comments are incorporated herein by 
reference. Each of Claims 2, 3, 4, 5, and 6 recites at least 
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AFTER FINAL EXPEDITED PROCEDURE 

one key to provide access to a resource on said data 
coinmunications network; a resource identifier^ a resource 
server peer group ID; and a randomized user ID. The cited 
sections of Reiche and the cited sections of Rode failed to 
teach the foregoing recited elements, as previously discussed. 
A prima facie obviousness rejection has not been made. 
Applicants respectfully request reconsideration and withdrawal 
of the obviousness rejection of each of Claims 2, 3, 4, 5, 
and 6, 

Claims 1 to 6 remain in the application* For the 
foregoing reasons. Applicants respectfully request allowance of 
all pending claims. If the Examiner has any questions relating 
to the above, the Examiner is respectfully requested to 
telephone the undersigned Attorney for Applicant (s) . 

CERTTFICATE OF TRANSMISSION 
I hertby certify that thia correepondence is being RSSpectf Ully submitted, 
(ACsimile transmitted to the i;.S. latent and 
Txadcmaric Office* Pax No. (571) aTS-- 3300, oa 
OctOibGr 13, 200$. 



October 13, 7006 
Date of Signature 





Rivkah Yoimg 



Forrest GunnjS 
Attorney for Applicant (s) 
Reg- No- 32,899 
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